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(54) Methods and apparatus for permitting transactions across firewalls 



(57) Methods and apparatus for enabling document 
access across a firewall are disclosed. A method of ac- 
cessing a document across a firewall includes obtaining 
a document access request on the first side of the fire- 
wall, where the document access request specifies a 
document control command and an associated file 
name. The document access request is then packaged 
in at least one client e-mail. The client e-mail is then sent 
across the firewall to the second side of the firewall. One 
or more acknowledgement e-mails are then received 
across the firewall from the second side of the firewall, 
where the acknowledgement e-mails specify a status of 
the executed document control command. In addition, 
a method of providing access to a document across a 
firewall includes receiving a client e-mail across the fire- 
wall from the first side of the firewall, where the client e- 
mail includes a document access request specifying a 
document control command and an associated file 
name. The document access request is then executed 
such that a status of the executed document access re- 
quest is obtained. An acknowledgement e-mail specify- 
ing the status is then sent across the firewall to the first 
side of the firewall. 
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Description 

BACKGROUND OF THE INVENTION 

1 . FIELD OF THE INVENTION 

[0001] The present invention relates generally to 
computer software and computer network applications. 
More particularly, the present invention relates to meth- 
ods and apparatus for permitting transactions across a 
firewall via Electronic Mail. 

2. DISCUSSION OF RELATED ART 

[0002] In today's technologically advanced society, 
companies and organizations often have a large 
number of computers as well as employees. Since mul- 
tiple sites are often maintained, it is common for such 
entities to maintain the computer systems in locations 
that are situated a large distance apart from one anoth- 
er. Thus, it is often desirable to provide a means for com- 
municating among the employees at these separate lo- 
cations. In addition, resources such as programs and 
data are often shared among these employees. Accord- 
ingly, such entities often enable such communication 
and resource sharing through one or more networks. 
[0003] In addition to providing communication among 
computers within a single entity (e.g., company), it is of- 
ten desirable to enable communication with outside net- 
works. By way of example, the Internet is a resource 
that is widely used by the general population. However, 
many entities store valuable and confidential informa- 
tion on internal networks. Accordingly, it is important that 
the security and integrity of this information be pre- 
served while permitting access to and from outside net- 
works. 

[0004] While it is desirable to permit flow of informa- 
tion between internal networks and outside networks, it 
is important that access to confidential information be 
limited to intended individuals (e.g., individuals em- 
ployed within the company). Similarly, it is imperative 
that the integrity of data and programs within an entity's 
system be protected from corruption. This is particularly 
important in view of the recent popularity of the Internet. 
Thus, many companies implement firewalls to filter traf- 
fic entering and leaving the network 
[0005] One standard firewall configuration includes 
two routers that filter packets and an application gate- 
way. One router filters outgoing packets while another 
router filters incoming packets according to various fil- 
tering rules. Typically, tables store these filtering rules, 
which may list, for example, those sources and destina- 
tions that are acceptable. In addition, the application 
gateway operates at the application leveL By way of ex- 
ample, an application gateway may be set up to exam- 
ine the content of each incoming or outgoing e-mail 
message. In this manner, an added level of security may 
be added to any network. 



[0006] While a firewall is desirable in many instances 
to provide a high level of security in a given network, 
such a security feature may create undesirable limita- 
tions. For instance, it is common for two or more com- 

s panies to collaborate tn their development efforts. In or- 
der to facilitate this joint development, it may desirable 
to permit employees of one company to access docu- 
ments maintained by another company. However, it is 
typically impossible to share documents such as source 

jo code where a firewall separates the two networks. 

[0007] In view of the above, it would be beneficial if a 
firewall could be selectively bypassed to permit source 
code or other files on one side of a firewall to be ac- 
cessed by an entity on another side of the firewall. 

15 

SUMMARY 

[0008] An invention is described herein that enables 
document access across a firewall. This is accom- 

20 plished via a document access request sent via e-mail. 
In this manner, documents such as source code files 
may be sent and received across a firewall. 
[0009] According to one aspect, a method of access- 
ing a document across a firewall includes obtaining a 

25 document access request on the first side of the firewall, 
where the document access request specifies a docu- 
ment control command and an associated file name. 
The document access request is then packaged in at 
least one client e-mail. The client e-mail is then sent 

30 across the firewall to the second side of the firewall. One 
or more acknowledgement e-mails are then received 
across the firewall from the second side of the firewall, 
where the acknowledgement e-mails specify a status of 
the executed document control command. 

35 [0010] According to another aspect, a method of pro- 
viding access to a document across a firewall includes 
receiving a client e-mail across the firewall from the first 
side of the firewall, where the client e-mail includes a 
document access request specifying a document con- 

40 trot command and an associated file name. The docu- 
ment access request is then executed such that a status 
of the executed document access request is obtained. 
An acknowledgement e-mail specifying the status is 
then sent across the firewall to the first side of the fire- 

45 wall. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0011] The invention, together with further advantag- 
so es thereof, may best be understood by reference to the 
following description taken in conjunction with the ac- 
companying drawings in which: 

[0012] FIG. 1 is a block diagram illustrating a system 
in which the present invention may be implemented. 
55 [0013] FIG. 2 is a block diagram illustrating an exem- 
plary e-mail message that may be sent across a firewall 
to request access to a document according to an em- 
bodiment of the invention. 
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[0014] FIG. 3 is a flow diagram illustrating a method 
of implementing the source code control system on the 
client side of a firewall according to an embodiment of 
the invention. 

[0015] FIG. 4 is a flow diagram illustrating a method 
of packaging a client code access request in one or 
more client e-mail messages as shown at block 304 of 
FIG. 3. 

[0016] FIG. 5A is a flow diagram illustrating a method 
of handling an acknowledgement of the status of the ex- 
ecuted code access request as shown at block 310 of 
FIG. 3. 

[0017] FIG. 5B is a block diagram illustrating exem- 
plary formats for an acknowledgement e-mail commu- 
nicating the status of the executed code access request 
and reply composed from the acknowledgement e-mail. 
[0018] FIG. 6A is a flow diagram illustrating one meth- 
od of providing access to source code across a firewall 
(i.e., on the server side of the firewall) according to an 
embodiment of the invention. 

[0019] FIG. 6B is a flow diagram illustrating one meth- 
od of implementing the source traffic coordinator shown 
at block 110 of FIG. 1. 

[0020] FIG. 7 is a flow diagram illustrating one method 
of parsing the client e-mail to obtain information associ- 
ated with the code access request. 
[0021] FIG. 8A is a flow diagram illustrating one meth- 
od of implementing the execution engine shown at block 
114of FIG. 1. 

[0022] FIG. 8B is a block diagram illustrating an ex- 
emplary command data structure that may be used to 
store information associated with the code access re- 
quest. 

[0023] FIG. 9 is a flow diagram illustrating one method 
of implementing the acknowledgement server as shown 
at block 116. 

[0024] FIG. 10 is a block diagram illustrating a typical, 
general-purpose computer system suitable for imple- 
menting the present invention. 

DETAILED DESCRIPTION OF THE PREFERRED 
EMBODIMENTS 

[0025] The present invention permits a user to access 
and modify information maintained on a network that is 
protected by a firewall. For instance, the present inven- 
tion may be used to enable employees of one company 
to access documents maintained by another company. 
This is particularly useful where multiple companies are 
collaborating on a project where documents such as 
source code are being produced. It is important to note 
that such document access may be implemented even 
where a firewall separates the two networks. More par- 
ticularly, the present invention enables a user to access 
a single set of information (e.g., source code) that is 
stored on a system protected by a firewall. This is ac- 
complished via a document access request sent via e- 
mail, as will be described with reference to the following 



figures. In the following description, the portion request- 
ing access to a document will be referred to as the client 
portion, while the portion executing the document ac- 
cess request will be referred to as the server portion. In 

5 addition, the server portion may provide a status or other 
information across the firewall to the client portion upon 
completion of execution. The present invention will de- 
scribed as accessing a source code file. However, the 
present invention may equally apply to documents (e. 

10 g., files) other than source code. 

[0026] A block diagram illustrating a system in which 
the present invention may be implemented is presented 
in FIG. 1. In order to simplify the illustration, each block 
illustrates a separate process. When a client wishes to 

is access or modify a set of source code, the client may 
send a "client code access request" via source control 
engine 1 02. More particularly, the client code access re- 
quest may include a source code control command as 
well as an associated file name. By way of example, the 

20 source code control command may be a "check in," 
"check out,* "view," or "copy" command. The source 
code control command will therefore allow a client to 
check in source code associated with the specified file 
name, check out the source code in the specified file 

25 name, view or copy the source code made available in 
the specified file. 

[0027] Once a user has entered the client code ac- 
cess request via the source control engine 102 through 
a menu or other mechanism, the client code access re- 

30 quest is sent to the client interface engine 104. The client 
interface engine 104 then packages the client code ac- 
cess request in one or more client e-mails 106 and 
sends these client e-mail messages across firewall 108 
to source traffic coordinator 110. 

35 [0028] Each client may send multiple code access re- 
quests. Moreover, client code access requests may be 
sent by multiple clients. Therefore, the source traffic co- 
ordinator 110 is responsible for routing the client code 
access requests as they are received to the appropriate 

40 process block on one or more servers. One method of 
implementing the source traffic coordinator 110 will be 
described in further detail with reference to FIG. 6B. 
[0029] In order to execute each code access request, 
the code access request is parsed into the appropriate 

45 components (e.g., source code control command and 
file name). Thus, the source traffic coordinator 110 
routes each client code access request to a parser 112 
adapted for parsing a client code access request, as will 
be described in further detail with reference to FIG. 7. 

50 Once parsed, the components may be temporarily 
stored in a data structure for further processing. 
[0030] Upon completion of the parsing, the parsed cli- 
ent code access request is forwarded to an execution 
engine 114 for execution. The execution engine 114 

55 then executes the client code access request. By way 
of example, the execution engine may execute a code 
control command such as a "check in" command to 
check in an updated version of selected source code 
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associated with the specified file name. One method of 
implementing the execution engine 114 will be de- 
scribed in further detail below with reference to FIG. 8A. 
[0031] Once execution is completed, the execution 
engine 114 transfers control to an acknowledgement 
module or server 116 to obtain and transmit the status 
(e.g., success or failure) of the access request. More 
particularly, the acknowledgement server 116 compos- 
es an acknowledgement e-mail 118 indicating the status 
(e.g., success or failure) of the executed command. By 
way of example, the acknowledgement e-mail 118 may 
indicate that the source code has been successfully 
checked in. As yet another example, the acknowledge- 
ment e-mail 118 may include a portion of source code 
that has been successfully checked out. One method of 
implementing the acknowledgement server 116 will be 
described in further detail below with reference to FIG. 
9. The acknowledgement server 116 then sends the ac- 
knowledgement email 118 to the client interface engine 
104, which may compose a reply suitable for the origi- 
nator of the access request. Once the client interface 
engine 1 04 has composed the reply, the reply is forward- 
ed to the source control engine 102 to be routed to the 
originator of the access request. In this manner, a user 
may access and update a single set of source code 
across a firewall 1 02 via e-mail. Although the operations 
on each side of the firewall are shown as separate 
blocks, these operations may be performed on one or 
more servers. Accordingly, the present invention may 
be advantageously used to implement an effective 
source code control system that may be accessed by 
multiple companies. 

[0032] As described above, each code access re- 
quest specifying a code control command and associ- 
ated file name is packaged in one or more client e-mails. 
FIG. 2 is a block diagram illustrating an exemplary client 
e-mail message that may be sent across a firewall to 
request access to a document (e.g., source code) ac- 
cording to an embodiment of the invention. As shown, 
the client e-mail message 200 includes a mail header 
202 including a source address 204 and a destination 
address 206. Moreover, the present invention preferably 
handles only those e-mails that are addressed to the 
source code control system of the present invention. It 
is therefore desirable to implement a password or iden- 
tifier code 208 that may be used to designate those e- 
mails that are addressed to the source code control sys- 
tem. In this manner, e-mails erroneously received by the 
source code control system may be discarded. As de- 
scribed above, a client code access request 210 in- 
cludes a source code control command 212 and a file 
name associated with the source code control com- 
mand 212. The file name 214 therefore permits the 
source code control system to access the specified file 
214. In addition, if the command 21 2 is a check in com- 
mand, the source code being checked in may be ap- 
pended as attachment 216. 

[0033] It may be necessary to send the client code ac- 



cess request in multiple e-mails. By way of example, 
when a file being checked into the source code control 
system is large, it may be fragmented into smaller por- 
tions, which may then be sent in separate client e-mails, 
s Accordingly, the number of client e-mail packets 218 to 
be sent in order to complete the client code access re- 
quest may be specified in each client e-mail message 
200. In this manner, the source traffic coordinator may 
easily determine which client e-mails correspond to a 
io single code access request. 

[0034] As shown and described above with reference 
to FIG. 1 , the source code control system is implement- 
ed on both sides of the firewall. Thus, on the client side 
of the firewall, the client (i.e., client portion) must be ca- 
15 pable of sending a client code access request including 
a source code control command as well as receiving the 
status of the request across the firewall. In addition, the 
source code control system executes the source code 
control commands and provides an acknowledgement 
20 of the status of these commands on the opposite side 
of the firewall (i.e., server portion). 
[0035] One method of implementing the client portion 
of the source code control system shown in FIG. 1 is 
illustrated in FIG. 3. The process begins at block 300 
25 and at block 302, the source control engine obtains and 
sends the desired source code control command and 
associated file name to the client interface engine. More 
particularly, the source code control command and as- 
sociated file name may be obtained via a menu, file, or 
30 other mechanism. The client interface engine then pack- 
ages the source code control command and associated 
file name in one or more client e-mails at block 304, as 
will be described in further detail below with reference 
to FIG. 4. The client interface engine then sends the di- 
ss ent e-mail(s) to the source traffic coordinator at block 
306. The client then waits for a status acknowledgement 
regarding the status of execution of the source code 
control command at block 308. Once the acknowledge- 
ment is received, the status acknowledgement is han- 
40 died at block 310, as will be described in further detail 
below with reference to FIG. 5A. More particularly, the 
status acknowledgement may be handled such that no- 
tification of the status is sent to the originator of the doc- 
ument access request. In this manner, the originator 
45 may be notified of any errors that occurred during exe- 
cution of the document access request. The process 
ends at block 312. Although the previously described 
process refers to one document access request, each 
client may send multiple document access requests. 
so [0036] As described above with reference to FtG. 3, 
each code access request is packaged in one or more 
client e-mails to be transmitted across the firewall to be 
processed by the server portion of the source code con- 
trol system. FIG. 4 is a flow diagram illustrating a method 
55 of packaging a client code access request in one or 
more client e-mail messages as shown at block 304 of 
FIG. 3. As will be described, the process fills the fields 
of one or more client e-mail messages such as that il- 
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lustrated in FIG. 2, and sends the client e-mail messag- 
es across the firewall for execution of the corresponding 
access request. The process begins at block 400 and 
at block 402, it is determined whether the source code 
control command is a "check in" command indicating 
that source code in the associated identified file is being 
checked into the source code control system. If the com- 
mand is a check in command, the associated file is iden- 
tified at block 404 and the size of the file is determined 
at block 406. The size of the file may then be used to 
ascertain the number of e-mails that are to be sent in 
order to complete the command. If the command is not 
a check in command, steps 404 and 406 are bypassed 
and the process continues to package the e-mail in 
blocks 408 through 420. As shown, the mail header in- 
formation such as source and destination addresses is 
entered in the client e-mail packet at block 408. Next, at 
block 410, a password/identifier code is entered to indi- 
cate that the e-mail is addressed to the source code con- 
trol system. The source code control command (e.g., 
check in command) is entered at block 41 2 and the as- 
sociated file name is similarly entered at block 414. In 
addition, if the command is a check in command, the 
source code is appended to the e-mail as an attachment 
at block 41 6. In addition, the number of e-mails required 
to complete the command is entered in the client e-mail 
at block 418. In this manner, the fields of a client e-mail 
may be filled in order to transmit an access request 
across the firewall. If it is determined at block 419 that 
each of the number of e-mails associated with the cor- 
responding access request has been composed and 
sent, the process ends at block 420. Alternatively, the 
process continues at block 408 to package the remain- 
ing client e-mail messages associated with the access 
request. In this manner, one or more client e-mail mes- 
sages such as that shown in FIG. 2 may be packaged 
by the client to execute a single source code control 
command. 

[0037] Once a source code control command provid- 
ed in a client e-mail message is executed, acknowledge- 
ment of such execution is sent back to the client as the 
source of the client e-mail message. FIG. 5A is a flow 
diagram illustrating a method of handling an acknowl- 
edgement of the status of the executed code access re- 
quest as shown at block 31 0 of FIG. 3. The process be- 
gins at block 500 and at block 502, an acknowledgement 
e-mail is received by the client interface engine from an 
acknowledgement server. As described above, a pass- 
word may be used to indicate those e-mails that are to 
be processed by the source code control system. Thus, 
the password provided by the client in the client e-mail 
message may similarly be provided in the return ac- 
knowledgement e-mail to indicate that the e-mail has 
been processed by the source code control system. If it 
is determined at block 504 that the password is invalid, 
the e-mail is ignored at block 506 and the process com- 
pletes at block 508. However, if the password is valid, a 
reply to the original client source code access request 



is created based upon the information in the acknowl- 
edgement e-mail at block 510. In this manner, selected 
information provided in the acknowledgement e-mail 
may be used to compose a reply suitable for the origi- 

5 nator of the source code access request. 

[0038] As described above, an attachment to the cli- 
ent e-mail message may be supplied when code is being 
checked into the source code control system. Similarly, 
an attachment to the acknowledgement e-mail message 

io may be provided when code is being checked out of the 
source code control system. Thus, it is determined at 
block 512 whether there is an attachment to the ac- 
knowledgement e-mail. If there is an attachment, the at- 
tachment may be saved at block 51 4 for retrieval by the 

15 originator of the access request. The reply is then sent 
by the client interface engine to the source control en- 
gine at block 51 6 for distribution to the client that origi- 
nated the access request. The process ends at block 
518. Accordingly, a client may receive source code be- 

20 jng checked out of the source code control system as 
well as a status indicating the success or failure of the 
access request previously sent by the client. 
[0039] As described above with reference to FIG. 5A, 
upon completion of execution of each command, an ac- 

25 knowledgement e-mail is composed so that the status 
of the access request may be supplied to the client. In 
addition, a reply may be composed from selected infor- 
mation (e.g., status) provided in the acknowledgement 
e-mail. FIG. 5B is a block diagram illustrating exemplary 

30 formats for an acknowledgement e-mail communicating 
the status of the executed code access request and re- 
ply composed from the acknowledgement e-mail. As 
shown, an acknowledgement e-mail 520 includes a 
header 522 specifying source 524 and destination 526 

35 addresses. In addition, a status 528 associated with the 
client code control command is provided. By way of ex- 
ample, the status 528 may indicate that the check in of 
the file was successful where the client code control 
command is a check in command. The password 529 

40 that indicates that the e-mail has been processed by the 
source code control system may also be provided. In 
addition, a log file may be maintained indicating that the 
command has been executed and any information per- 
taining to this execution. Thus, a confirmation code 530 

45 associated with this log entry may be provided to the 
client to permit the client to verify that the command has 
been successfully executed. In addition, the file name 
532 associated with the executed command may be 
provided. As described above, where the client code 

50 control command is a check out command, the content 
of the file (e.g., source code) being checked out of the 
source code control system may be provided as an at- 
tachment file 534 to the acknowledgement e-mail. In ad- 
dition, the number of e-mails to complete the command 
55 is specified at 536. By way of example, multiple ac- 
knowledgement e-maits may be provided where a file 
being checked out of the source code control system is 
large. 
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[0040] Although one or more acknowledgement e- 
mails indicating the status ot the executed command 
has previously been composed, the content and format 
of the acknowledgement e-mail may not be suitabte for 
the client issuing the command. In addition, as indicated 
above, for each executed command, there may be mul- 
tiple acknowledgement e-mails. For instance, as de- 
scribed above, where the command is a check out com- 
mand, each acknowledgement e-mail may contain a 
portion of a checked out file as an attachment to the ac- 
knowledgement e-mail. Therefore, there may be multi- 
ple acknowledgement e-mails associated with an exe- 
cuted command. As a result, it may be desirable to com- 
pose a single reply suitable for transmission to the client 
as source of the command. Thus, a reply 538 is com- 
posed from one or more associated acknowledgement 
e-mails 520. More particularly, the reply 538 may include 
a status 540 and confirmation code 542 such as those 
provided in the acknowledgement e-mail. In addition, a 
file name 544 that identifies the executed source code 
control command may be supplied. By way of example, 
where a client receives a "check in successful" reply, it 
is desirable to identify the file that has been checked in. 
As yet another example, where a client receives a 
"check out successful" reply, it is desirable to identify the 
file name or location of the file that was received in the 
attachment to the acknowledgement e-mail(s). Accord- 
ingly, the client may later obtain the file that has been 
retrieved from the system, update the file, and check the 
updated file back into the source code control system. 
[0041] As described above, the client is capable of 
transmitting client code access requests and receiving 
acknowledgement of the status these requests. Similar- 
ly, on the opposite side of the firewall, the source code 
control system executes the client code access re- 
quests and provides acknowledgement of this execu- 
tion. The operations performed to successfully execute 
each client code access request and provide acknowl- 
edgement upon completion of execution are described 
with reference to FIGS. 6A through 9. 
[0042] As shown and described with reference to FIG. 
1 , once a document access request is sent across a fire- 
wall, the document access request is executed on the 
server side of the firewall. FIG. 6A is a flow diagram il- 
lustrating one method of providing access to source 
code across a firewall (i.e. , on the server side of the fire- 
wall) according to an embodiment of the invention. The 
process begins at block 61 8 and at block 620, the source 
traffic coordinator receives a client e-mail including a 
code access request across the firewall. The client e- 
mail is then routed to the parser, which parses the code 
access request at block 622 such that the code access 
request may be executed. The execution engine exe- 
cutes the parsed code access request at block 624. Up- 
on completion of execution, a status indicating success 
or failure of the executed code access request may be 
obtained by the execution engine. The status is then for- 
warded to the acknowledgement server. At block 626, 



the acknowledgement server then composes and sends 
an acknowledgement e-mail specifying the status of the 
executed code access request, as well as other infor- 
mation identifying the code access request. The proc- 
5 ess ends at block 628. In this manner, a client e-mail is 
routed by the source traffic coordinator to the parser and 
executed. In response, one or more acknowledgement 
e-mails are composed and sent to communicate the sta- 
tus of the corresponding access request. 
w [0043] Multiple clients may wish to access the source 
code control system. Moreover, each client may issue 
more than one access request. As a result, it is desirable 
to provide a source traffic coordinator for routing each 
access request as it is received by the system. As shown 
15 in FIG. 6B, one method of implementing the source traf- 
fic coordinator shown at block 11 Oof FIG. 1 is presented. 
The process begins at block 602 and at block 604, the 
source traffic coordinator listens for incoming mail at 
block 604. When an e-mail is received at block 606, it is 
20 preferable to discard those e-mails that are not ad- 
dressed to the source code control system. Thus, at 
block 608, it is determined whether the password/code 
identifier is valid. If the password is not valid, the e-mail 
may be ignored or discarded at block 610 and the proc- 
2S ess completes at block 61 2. If the password is valid, the 
e-mail is then passed to the parser at block 614. The 
process ends at block 616. In this manner, the source 
traffic coordinator may route client e-mails as they are 
received across the firewall. 
30 [0044] In order to execute the source code access re- 
quest transmitted in the client e-mail, information such 
as the code control command and associated file name 
are obtained from the client e-mail. This is accomplished 
through the use of a parser. Thus, once the client e-mail 
35 is received by the parser, the parser parses the e-mail 
to obtain information associated with the source code 
access request. One method of parsing the client e-mail 
to obtain information associated with the code access 
request as shown at block 112 of FIG. 1 is presented in 
40 FIG. 7. As shown, the parser begins at block 702 and at 
block 704, the header information, including source and 
destination addresses, are obtained from the e-mail. 
Next, the command is obtained from the client e-mail at 
block 706 and the associated file name is obtained at 
45 block 708. In addition, the number of client e-mails that 
are to be received in order to complete the command is 
obtained at block 710. 

[0045] Once the client e-mail has been parsed, the in- 
formation may be stored in a command data structure. 

50 The command data structure may therefore be created 
at block 71 2 to temporarily store this obtained informa- 
tion. Moreover, since multiple users may each send 
more than one e-mail, a transaction identifier may be 
associated with the command data structure for each 

55 client e-mail being handled by the source code control 
system. 

[0046] In addition to parsing the information in the cli- 
ent e-mail, the client e-mail may include an attachment 
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containing source code that is being checked in to the 
system. Thus, it is determined at block 714 whether the 
command is a check in command. If the command is a 
check in command, the attachments are concatenated 
(or all e-mails sent to complete the command. In other 
words, the attachment for each one of the number of 
client e-maits obtained at block 710 are concatenated. 
Thus, the attachment is obtained at block 716 and the 
attachment is concatenated at block 718 to previously 
retrieved attachments associated with the command. In 
this manner, source code or other documents being 
checked in to the system may be constructed from mul- 
tiple attachments. 

[0047] If it is determined at block 70 that the parser 
has not completed parsing the number of client e-mails 
sent to complete the command, the next e-mail is ob- 
tained at block 722 and the process continues at block 
704. In this manner, information in each client e-mail 
may be retrieved. Therefore, if the newly received client 
e-mail is associated with the previous access request, 
concatenation of the attachment is performed as de- 
scribed above. However, if all e-mails associated with 
the command have been parsed, the parser indicates 
that parsing has been completed at block 724. More par- 
ticularly, the parser may send a token to the execution 
engine indicating that parsing is completed as well as a 
transaction identifier associated with the transaction. 
The execution engine may therefore identify the com- 
mand data structure and retrieve any associated files 
through the use of the transaction identifier. The process 
ends at block 726. 

[0048] Once the transaction identifier is received by 
the execution engine, the execution engine may identify 
the information associated with the command to be ex- 
ecuted. The information may therefore be obtained in 
order to execute the command. One method of imple- 
menting the execution engine as shown at block 114 of 
FIG. 1 is illustrated in FIG. 8A. The process begins at 
block 802 and at block 804, the command data structure 
associated with the transaction identifier is retrieved. 
The command is then obtained from the command data 
structure at block 806. Similarly, the file name associat- 
ed with the command is obtained from the command da- 
ta structure at block 808. The command and the file 
name are then supplied as parameters to a program ca- 
pable of executing the source code control commands 
(e.g., check in, check out) at block 810. By way of ex- 
ample, a Source Code Control System (SCCS), provid- 
ed as a standard utility with Solaris Operating systems, 
is available from Sun Microsystems, Inc., located in Palo 
Alto, CA. The output is then obtained from the called 
program and managed at block 81 2. By way of example, 
the output may include the status (e.g., fail or pass) of 
the command execution which may then be stored in 
the command data structure. A token indicating that the 
command has been executed and the transaction iden- 
tifier may then be sent to the acknowledgement server 
at block 814. The process ends at block 816. 



[0049] As described above with reference to FIGS. 7 
and 8A, information associated with a code access re- 
quest may be stored temporarily until the request is 
completed and the status is communicated to the client 

5 transmitting the code access request. Referring now to 
FIG. 8B, a block diagram illustrating an exemplary com- 
mand data structure that may be used to store informa- 
tion associated with the code access request. As shown, 
a command data structure 818 may include a transac- 

10 tion identifier 820, header information 822 such as 
source 824 and destination 826 addresses. In addition, 
the command data structure 818 may further include the 
command to be executed 828, the file name 830 asso- 
ciated with the command, and the number of e-mails 

15 832 required to complete execution of the command. 
Once execution of the command is complete, output 834 
obtained from the called program such as a status (e. 
g., pass or fail) may be stored in the command data 
structure. Each command data structure may be made 

20 available to the source traffic coordinator, the parser, the 
execution engine, and the acknowledgement server in 
a common memory location. In addition, any files iden- 
tified by the file name 830 may be temporarily stored in 
a common memory location. Once execution and ac- 

2S knowledgement of each command is performed, this 
memory may be re-atlocated as necessary. 
[0050] When the acknowledgement server receives 
notification that the command has executed, it then 
composes an appropriate acknowledgement e-mail 

30 from the information in the command data structure. 
One method of implementing the acknowledgement 
server as shown at block 1 1 6 is presented in FIG. 9. The 
process begins at block 902 and at block 904. the com- 
mand data structure associated with the transaction 

35 identifier is retrieved. The status (e.g., pass or fail) is 
then obtained from the command data structure at block 
906. In addition, the confirmation code is obtained from 
the command data structure at block 908. Next, at block 
910, the file name is obtained from the command data 

40 structure. In addition, the executed command (e.g., 
check in) may be obtained from the command data 
structure at block 912. 

[0051] Once all information that is to be provided in 
an acknowledgement e-mail is obtained from the com- 

45 mand data structure, any associated file is then re- 
trieved. By way of example, when a file is checked out 
of the system, it is sent in one or more attachments to 
the client via the client interface engine. Thus, if it is de- 
termined at block 914 that the command is a check out 

so command, the file identified by the obtained file name is 
located at block 91 6. The size of the identified file is then 
determined at block 91 8 to ascertain the number of ac- 
knowledgement e-mails that are to be sent in order to 
complete the command. 

55 [0052] For each of the number of acknowledgement 
e-mails to be sent, blocks 920 through 934 are per- 
formed. Thus, at block 920, header information includ- 
ing source and destination addresses are provided in 
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the acknowledgement e-mail. The destination address 
may be obtained from the source address provided in 
the command data structure or from a usemame data- 
base. In addition, the password is entered at block 922, 
where the password indicates that the acknowledge- 
ment e-mail has been handled by the source code con- 
trol system. 

[0053] A command status 924 indicating the com- 
mand (e.g., check in) and execution status (e.g., suc- 
cessful) are entered at block 924. In addition, at block 
926, the confirmation code is entered to permit a user 
to verify that a command has executed successfully. In 
addition, the file name 928 may be provided to permit a 
user to identify which file has, for example, been 
checked in or out of the source code control system. An 
attachment is appended to the acknowledgement e-mail 
if appropriate at block 930. By way of example, if the 
command is a check out command, an attachment con- 
taining at least a portion of the file is appended as an 
attachment. The number of acknowledgement e-mails 
that are to be sent in order to transmit all information 
associated with the executed command is then entered 
at block 932. The acknowledgement e-mail is then sent 
to the client interface engine at block 934. If it is deter- 
mined at block 936 that each of the number of acknowl- 
edgement e-mails associated with the executed com- 
mand have been sent, all temporary memory such as 
that used to store the command data structure(s) as well 
as files that have been checked out may be deleted at 
block 938. If it is determined at block 936 that one or 
more acknowledgement e-mails associated with the ex- 
ecuted command remain to be sent, the remaining ac- 
knowledgement e-mails are composed and sent at 
block 920. The process ends at block 940. 
[0054] As previously described, the present invention 
enables information that is stored on a network to be 
retrieved and modified, even where the network is pro- 
tected by a firewall. The present invention therefore pro- 
vides numerous advantages since entities may share a 
single set of documents without modifying or eliminating 
the firewall separating the entities. Accordingly, through 
the application of the present invention, a balance may 
be achieved between security and the level of informa- 
tion sharing that is crucial to technological advance- 
ment. 

[0055] The source code control system of the present 
invention may be implemented in a variety of ways. By 
way of example, the present invention may be imple- 
mented in an object-oriented language. Moreover, the 
present invention may generally be implemented on any 
suitable computer system. FIG. 10 illustrates a typical, 
general-purpose computer system 1002 suitable for im- 
plementing the present invention. The computer system 
1002 includes any number of processors 1004 (also re- 
ferred to as central processing units, or CPUs) that may 
be coupled to memory devices including primary stor- 
age device 1 006 (typically a read only memory, or ROM) 
and primary storage device 1008 (typically a random ac- 



cess memory, or RAM). As is well known in the art, ROM 
acts to transfer data and instructions uni-directionally to 
the CPUs 1004, while RAM is used typically to transfer 
data and instructions in a bi-directional manner. Both the 

5 primary storage devices 1006, 1008 may include any 
suitable computer-readable media. The CPUs 1004 
may generally include any number of processors. 
[0056] A secondary storage medium 1010, which is 
typically a mass memory device, may also be coupled 

10 bi-directionally to CPUs 1004 and provides additional 
data storage capacity. The mass memory device 1010 
is a computer-readable medium that may be used to 
store programs including computer code, data, and the 
like. Typically, the mass memory device 1010 is a stor- 

15 age medium such as a hard disk which is generally slow- 
er than primary storage devices 1006, 1008. 
[0057] The CPUs 1004 may also be coupled to one 
or more input/output devices 1012 that may include, but 
are not limited to, devices such as video monitors, track 

20 balls, mice, keyboards, microphones, touch-sensitive 
displays, transducer card readers, magnetic or paper 
tape readers, tablets, styluses, voice or handwriting rec- 
ognizers, or other well-known input devices such as, of 
course, other computers. Finally, the CPUs 1 004 option- 

25 ally may be coupled to a computer or telecommunica- 
tions network, e.g., an internet network or an intranet 
network, using a network connection as shown gener- 
ally at 1014. With such a network connection, it is con- 
templated that the CPUs 1 004 might receive information 

30 from the network, or might output information to the net- 
work in the course of performing the below-described 
method steps. Such information, which is often repre- 
sented as a sequence of instructions to be executed us- 
ing the CPUs 1004, may be received from and outputted 

35 to the network, for example, in the form of a computer 
data signal embodied in a carrier wave. 
[0058] Although illustrative embodiments and appli- 
cations of this invention are shown and described here- 
in, many variations and modifications are possible which 

40 remain within the concept, scope, and spirit of the in- 
vention, and these variations would become clear to 
those of ordinary skill in the art after perusal of this ap- 
plication. For instance, the present invention is de- 
scribed as enabling access to source code across a fire - 

45 wall. Although the above description refers to "source 
code," the present invention may be used to access or 
modify any document or file across a firewall. Moreover, 
the above described process blocks are illustrative only. 
Therefore, accessing a file across a firewall may be ac- 

50 complished via e-mail using alternate process blocks. 
Accordingly, the present embodiments are to be consid- 
ered as illustrative and not restrictive, and the invention 
is not to be limited to the details given herein, but may 
be modified within the scope and equivalents of the ap- 

55 pended claims. 
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Claims 

1. A document control system (or providing access on 
a first side of a firewall to a file that is available on 
a second side of the firewall, the system comprising: 

a source control engine on the first side of the 
firewall, the source control engine adapted for 
obtaining a document access request specify- 
ing a document control command and a file 
name associated with the document control 
command; and 

a client interface engine in communication with 
the source control engine, the client interface 
engine adapted for composing a client e-mail 
including the document access request and 
sending the client e-mail across the firewall to 
the second side of the firewall. 

2. The document control system as recited in claim 1 , 
further including: 

a source traffic coordinator on the second side 
of the firewall and in communication with the 
client interface engine, the source traffic coor- 
dinator adapted for receiving the client e-mail 
from the client interface engine; 
a parser in communication with the source traf- 
fic coordinator and adapted for parsing the doc- 
ument access request to create a parsed doc- 
ument access request suitable for execution; 
and 

an acknowledgement module adapted for 
sending an acknowledgement e-mail across 
the firewall to the first side of the firewall, the 
acknowledgement e-mail specifying a status 
upon completion of the execution of the parsed 
document access request. 

3. The system as recited in claim 2, wherein the status 
indicates success or failure of the document access 
request. 

4. The system as recited in claim 2, wherein the doc- 
ument control command specifies at least one of 
check in, check out, view, or copy. 

5. The system as recited in claim 2, wherein the file 
name identifies a source code file. 

6. The document control system as recited in claim 1 , 
further including: 

a source traffic coordinator on the second side 
of the firewall and in communication with the 
client interface engine, the source traffic coor- 
dinator adapted for receiving the client e-mail 
from the client interface engine; 



a parser in communication with the source traf- 
fic coordinator and adapted for parsing the doc- 
ument access request; 

an execution engine in communication with the 
parser and adapted for executing the parsed 
document access request; and 
an acknowledgement module in communica- 
tion with the execution engine and adapted for 
sending an acknowledgement e-mail across 
the firewall to the first side of the firewall, the 
acknowledgement e-mail specifying a status of 
the executed access request. 

The document control system as recited in claim 6, 
wherein the acknowledgement e-mail is sent to the 
client interface engine, the client interface engine 
being adapted for composing a reply to the docu- 
ment access request from selected information pro- 
vided in the acknowledgement e-mail. 

The document control system as recited in claim 7, 
wherein the client interface engine sends the reply 
to the source control engine. 

A document control system for providing access on 
a first side of a firewall to a file that is available on 
a second side of the firewall, the system comprising: 

a source traffic coordinator on the second side 
of the firewall, the source traffic coordinator 
adapted for receiving an e-mail across the fire- 
wall from the first side of the firewall, the e-mail 
including a document access request specify- 
ing a document control command and a file 
name associated with the document control 
command; 

a parser in communication with the source traf- 
fic coordinator and adapted for parsing the doc- 
ument access request to create a parsed doc- 
ument access request suitable for execution; 
and 

an acknowledgement module adapted for 
sending an acknowledgement e-mail across 
the firewall to the first side of the firewall, the 
acknowledgement e-mail specifying a status 
upon completion of the execution of the parsed 
document access request. 

10. A method of accessing a document across a firewall 
having a first side and a second side, the method 
comprising: 

obtaining a document access request on the 
first side of the firewall, the document access 
request specifying a document control com- 
mand and an associated file name; 
packaging the document access request in at 
least one client e-mail; 
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sending the client e-mail across the firewall to 
the second side of the firewall; and 
receiving one or more acknowledgement e- 
mails across the firewall from the second side 
of the firewall, the one or more acknowledge- 
ment e-mails specifying a status of the execut- 
ed document control command. 

1 1 . The method as recited in claim 1 0, further including: 

handling the one or more acknowledgement 
e-mails to provide notification of the status of the 
executed document control command. 

12. The method as recited in claim 10, wherein pack- 
aging the document access request includes: 

determining whether the document control 
command is a check in command; 
wherein when it is determined that the docu- 
ment control command is a check in command, 
an attachment is appended to the client e-mail, 
the attachment including at least a portion of a 
file identified by the associated file name. 

1 3. The method as recited in claim 1 2, wherein append- 
ing includes: 

locating the file; and 

determining a size of the file to ascertain a 
number of client e-mails to be sent in order to 
complete the document control command. 

1 4. The method as recited in claim 1 3, further including: 

entering in the client e-mail the number of e- 
mails to complete the document control command. 

15. The method as recited in claim 10, wherein pack- 
aging the document access request includes: 

entering header information in the client e-mail, 
the header information including source and 
destination addresses; 

entering a password in the client e-mail, the 
password indicating that the client e-mail is to 
be handled by a document control system; 
entering the document control command in the 
client e-mail; and 

entering the file name associated with the doc- 
ument control command in the client e-mail. 

1 6. The method as recited in claim 1 5, further including: 

entering in the client e-mail a total number of 
client e-mails to be sent in order to complete the 
document access request. 

1 7. The method as recited in claim 1 1 , wherein handling 
the acknowledgement e-mails includes: 

creating a reply to the document access re- 



quest based on information in the one or more ac- 
knowledgement e-mails. 

1 8. The method as recited in claim 1 1 , wherein handling 
5 the acknowledgement e-mails includes: 

determining whether the one or more acknowl- 
edgement e-mails include a valid password; 
wherein when it is determined that the one or 

to more acknowledgement e-mails include a valid 

password, creating a reply to the document ac- 
cess request based on information in the one 
or more acknowledgement e-mails; and 
wherein when it is determined that the one or 

'5 more acknowledgement e-mails do not include 

a valid password, dropping the one or more ac- 
knowledgement e-mails. 

1 9. The method as recited in claim 1 1 , wherein handling 
20 the one or more acknowledgement e-mails in- 
cludes: 

determining whether the one or more acknowl- 
edgement e-mails include an attachment; and 
25 wherein when it is determined that the one or 

more acknowledgement e-mails include an at- 
tachment, saving the attachment. 

20. The method as recited in claim 19, wherein deter- 
30 mining whether the one or more acknowledgement 

e-mails include an attachment includes: 

determining whether the document control 
command is a check out command. 

35 21. A method of providing access to a document across 
a firewall having a first side and a second side, the 
method comprising: 

receiving a client e-mail across the firewall from 
40 the first side of the firewall, the client e-mail in- 

cluding a document access request specifying 
a document control command and an associat- 
ed file name; 

executing the document access request such 
45 that a status of the executed document access 

request is obtained; and 
sending an acknowledgement e-mail specify- 
ing the status across the firewall to the first side 
of the firewall. 

so 

22. The method as recited in claim 21 , further including: 

determining whether the client e-mail includes 
a valid password; and 
ss wherein when it is determined that the client e- 

mail does not include a valid password, drop- 
ping the client e-mail. 
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23. The method as recited in claim 21 , further including: 

parsing the client e-mail to obtain information 
associated with the document access request; 
determining whether the client e-mail includes 
an attachment; and 

wherein when it is determined that the client e- 
mail includes an attachment, concatenating the 
attachment to previously retrieved attachments 
associated with the document access request. 

24. The method as recited in claim 23, wherein deter- 
mining whether the client e-mai! includes an attach- 
ment includes determining whether the document 
control command is a check in command. 

25. The method as recited in claim 21 , further including; 

determining whether the document control 
command is a check out command; 
wherein when it is determined that the docu- 
ment control command is a check out com- 
mand, appending an attachment to the ac- 
knowledgement e-mail including at least a por- 
tion of a file identified by the file name associ- 
ated with the document control command. 

26. The method as recited in claim 25, wherein append- 
ing includes: 

locating the file identified by the file name; and 
determining a size of the file to ascertain a 
number of acknowledgement e-mails to be 
sent. 

27. The method as recited in claim 21 , further including: 

entering a header in the acknowledgement e- 
mail, the header including source and destina- 
tion addresses; 

entering a password in the acknowledgement 
e-mail, the password indicating that the ac- 
knowledgement e-mail has been handled by a 
document control system; and 
entering the file name associated with the doc- 
ument control command in the acknowledge- 
ment e-mail, wherein the status indicates suc- 
cess or failure of the document control com- 
mand. 

28. The method as recited in claim 27, further including: 

entering a confirmation code associated with 
the document access request in the acknowledge- 
ment e-mail. 

29. The method as recited in claim 27, further including: 

entering in the acknowledgement e-mail a to- 
tal number of acknowledgement e-mails that are to 



be received in association with the document ac- 
cess request. 

30. The method as recited in claim 21 , further including: 
s deleting information associated with the doc- 
ument access request from memory. 

31. A method of enabling document access across a 
firewall having a first side and a second side, the 

io method comprising: 

receiving on the second side of the firewall an 
e-mail sent from the first side of the firewall, the 
e-mail having an attached source code file; 
is unpacking the source code file on the second 

side of the firewall; and 

sending an acknowledgment e-mail from the 
second side of the firewall to the first side of the 
firewall to acknowledge receipt of the source 
20 code file. 

32. A computer-readable medium having thereon com- 
puter readable instructions configured for access- 
ing a document across a firewall having a first side 

25 and a second side, the instructions comprising: 

instructions for obtaining a document access 
request on the first side of the firewall, the doc- 
ument access request specifying a document 

30 control command and an associated file name; 

instructions for packaging the document ac- 
cess request in at least one client e-mail; 
instructions for sending the client e-mail across 
the firewall to the second side of the firewall; 

35 and 

instructions for receiving one or more acknowl- 
edgement e-mails across the firewall from the 
second side of the firewall, the one or more ac- 
knowledgement e-mails specifying a status of 

40 the executed document control command. 

33. A computer-readable medium having thereon com- 
puter readable instructions configured for providing 
access to a document across a firewall having a first 

45 side and a second side, the instructions comprising: 

instructions for receiving a client e-mail across 
the firewall from the first side of the firewall, the 
client e-mail including a document access re- 

so quest specifying a document control command 

and an associated file name; 
instructions for executing the document access 
request such that a status of the executed doc- 
ument access request is obtained; and 

55 instructions for sending an acknowledgement 

e-mail specifying the status across the firewall 
to the first side of the firewall. 
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